v3.17.5

Fixed

• SpotBugs-annotations dependency is suddenly needed in builds that do certain kinds of annotation processing. (Issue 1026)
• Significant fields error when testing a class with a field that has a Map with an array as its value type. (Issue 1027)

Changed

• Reverted the refactorings introduced in versions 3.17.2, 3.17.3 and 3.17.4, as they were causing more problems than they were solving. See this blog post for some background.

v3.17.4

• Fixes bug where the wrong generic type was provided when multiple fields of the same type but with different generic parameters exist. (Issue 1022)

Changed

• The internal instantiation logic has been further refactored, to be more robust and extensible for future enhancements.

v3.17.3

Fixed

• Fixes bug when passing a subclass of a field's type into #withPrefabValues() (which was introduced in the previous version). (Issue 1014)
• In Windows builds, the handling of line endings didn't work properly. (Issue 1015)

v3.17.2

Fixed

• It's now possible to pass a subclass of a field's type into #withPrefabValuesForField(). (Issue 1012)

Changed

• The internal instantiation logic has been further refactored, to be more robust and extensible for future enhancements.

v3.17.1

Fixed

• Instantiates java.sql.Date only when available, so EqualsVerifier no longer throws NoClassDefFoundError when it's not available (for instance, when running EqualsVerifier standalone instead of as part of a test suite). (Issue 746)

v3.17

• Fixes bug where the wrong generic type was provided when multiple fields of the same type but with different generic parameters exist. (Issue 1022)

Changed

• The internal instantiation logic has been further refactored, to be more robust and extensible for future enhancements.

v3.16.2

Changed

• The error message in some edge cases involving complex generics and abstract classes is now improved. (Issue 983)
• The line in the error message that shows the version of EqualsVerifier and the JDK, now also indicates whether EqualsVerifier runs on the classpath or the modulepath.

Deprecated

• withResetCaches() was once needed for use in Quarkus, but caches are now reset automatically on every run.

v3.16.1

Fixed

• IllegalArgumentException argument type mismatch when a field's type has a wildcard generic and the underlying type has a type bound (such as T extends Serializable). (Issue 940)
• AbstractMethodError when a the equals method in a field's class calls an abstract method. (Issue 938)

v3.16

Changed

• The error message in some edge cases involving complex generics and abstract classes is now improved. (Issue 983)
• The line in the error message that shows the version of EqualsVerifier and the JDK, now also indicates whether EqualsVerifier runs on the classpath or the modulepath.

Deprecated

• withResetCaches() was once needed for use in Quarkus, but caches are now reset automatically on every run.

v3.15.8

Fixed

• Final entities with @​GeneratedValue could not be verified. (Issue 929)

v3.15.7

Fixed

• StackOverflowError when a class has a field of a sealed type whose only permitted subtype has a reference to the original class. (Issue 920)

v3.15.6

Fixed

• Protected JPA entity getters were ignored. (Issue 909)

v3.15.5

Changed

• Check that getters are used for all generated JPA id fields. (Issue 892)

v3.15.4

Added

• A check for Scala with its -Xcheckinit flag switched on. This flag generates a field that should have been marked as synthetic, but isn't, so EqualsVerifier has to check for this field explicitly.

v3.15.3

Changed

• Improves error message when packages are not "open" to EqualsVerifier. (Issue 868)

v3.15.2

Fixed

• For JPA entities with a hashCode that doesn't use all fields, and with Warning.STRICT_HASHCODE suppressed, an error was thrown. (Issue 853)